Attribute-based access control (ABAC) is a known way to perform access control to resources. In ABAC, entities such as subjects, resources, actions, the environment, or other relevant entities, are described in terms of their attributes. An attribute may be assigned to reflect an identified property of such an entity, and an entity may have more than one attribute. Attributes of a subject may, for instance, be the subject's identity, or the subject's role in an organization.
A typical ABAC scenario is illustrated in FIG. 1a. In the figure, a subject (for example a user) 101 attempts to access a protected resource (for example a certain document) 102. The attempt is intercepted by a policy enforcement point (PEP) 103 which queries a policy decision point (PDP) 104 that will decide whether the subject 101 should be allowed access to the protected resource 102 or not. Along with, or included in, the access request 105, the PEP 103 can also include relevant attribute values, such as the identity of the subject 101 and the identity of the protected resource 102 that the subject 101 has attempted to access.
To make a decision, the PDP 104 evaluates the access request 105 against a policy 106. A policy 106 may reference attributes of entities and contain expressions of operators which operate on attribute values or the results of other expressions, and the policies may be expressed in a policy language such as for example the eXtensible Access Control Markup Language (XACML). Such a language may also be used to express the access request 105 sent from the PEP 103 to the PDP 104, and the same is true for an expected access decision 108 that is to be sent back to the PEP 103 from the PDP 104 after a decision has been made.
The values of attributes may come from various sources. They may be locally available in the PDP 104, either as provided by the PEP 103 (such as subject and resource identities, which may be included in the access request 105) or as other information objects available at the PDP 104, such as for instance the current system time or some other quantity that is independent of subject and resource. Values of attributes may be stored in, or made available via, a remote attribute source (RAS) and must then be remotely queried for. There may be multiple such RASs 107a-c, and some attributes may be available only after querying more than one RAS. Their values will then be a combined collection of the values which the various RASs have returned.
Remote attribute retrieval is typically configured such that there is a connector module that allows the PDP 104 to communicate with a RAS 107 by, typically, submitting a query to the RAS 107. The connector module has a configuration which contains the information required to connect to the RAS 107 which executes the query and returns the resulting values back to the connector module and the PDP 104. The connector module may be included in the PDP 104, or be located outside the PDP 104 in for example a policy information point (PIP, not shown) serving as an intermediary between the PDP 104 and a RAS 107. Independent of its location in this framework, a connector module may, however, be regarded as as a part of the PDP 104. After receiving the values of the remotely available attributes, the PDP 104 updates the policy 106 by substituting the values of the referenced attributes. After doing so, the PDP 104 evaluates the policy 106 and sends the access decision 108 back to the PEP 103. Based on the access decision 108, the PEP 103 finally either permits or denies the subject 101 access to the wanted protected resource 102, e.g. by selectively activating and deactivating hardware or software protection means.
The abovementioned way of evaluating an access request 105 against a policy 106 may lead to performance problems, in general, and inefficient use of network capacity in particular. This is true especially if the set of values that needs to be returned to the PDP 104 from the RAS 107 is large. For instance, it may be desirable to have an ABAC policy 106 which permits access to a resource 102 only once for a given subject (user) 101. Such a situation can be modeled by defining a multi-valued attribute on the resource 102 called “accessed_by_users”, and let the values of this attribute be the identities of the users who have accessed the resource 102 previously. Accordingly, the ABAC policy 106 will deny access if the identity of the user 101 attempting to access the resource 102 is found among the values of this attribute. However, if the resource is accessed by many users, the set of values in the multi-valued attribute “accessed_by_users” will grow large, and many values will need to be transferred from the remote attribute source to the PDP 104 before the PDP 104 can determine whether the identity of a user is to be found among the set of values of the attribute. There will also be a need for the PDP 104 to cache the received attribute values locally. This may lead to the above mentioned issues.
In the light of the above, an improved way of evaluating an access request against an ABAC policy 106 is thus required that reduces the needed amount of network capacity and PDP-side memory.